"sites" certificate problem with Outlook
Hi, I'm rather stuck on this problem. When starting Outlook I get two security alerts with the title "sites", saying the name on the certificate does not match the name of the site. A little background: I had to remove and reinstall the CAS (Client Access Role) service on a SBS 2008 server, to fix a problem where iPhones couldn't connect (the OPTIONS command was causing crashes, claiming a file didn't exist). I ran the SBS powershell script (provided by MS) to move the virtual directories from the Default Web Site (where they ended up after reinstalling CAS) to the SBS Web Applications site (where they should be for SBS), and the problem was fixed. Since then, Outlook on all the clients keeps complaining about this "sites" certificate. We're only using self-issued certificates. What is this "sites" address (which resolves to the server's IP) Outlook is trying to access? How can I make it happy again? Many thanks for any help you can provide, Russell
June 1st, 2011 7:48am

That probably means the bindings aren't correct. The first thing I would do is run the fix my network wizard in the SBS management console. That should correct the bindings for you. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
June 1st, 2011 8:45am

Thanks, but It found "Exchange SMTP connectors are invalid" but failed with the error "The server cannot connect the SMTP connectors. Ensure that Exchange is running, and then try again". Nobody is having trouble sending mail though. It may just be that I've changed them around from default to allow pop/smtp connections from outside, for authorised users. This has been running for over a month and not the cause of this recent problem. I can't find anything on the web as to why Outlook is trying to connect to "sites". Presumably there's a certificate around someone that includes this name, and somewhere else I need to tell to use it. I just have no idea where either are :( As a temporary workaround, I've changed the "sites" CNAME from "servername.domain.local" to "localhost". It's fixed the error from popping up, but obviously isn't a proper solution.
June 1st, 2011 12:44pm

If you ctrl + right click the outlook icon on the bottom right tray and do test email autoconfiguration, uncheck use check use guessmart and secure guessmart. In the results what are your URL values? Do you see "sites" listed anywhere? Can you explain what you mean when you change the "sites" cname from servername.domain.local to just localhost? i'm thinking your selfsign cert has just localhost. If so you need to make sure your internURLs are set to use localhost for your web services. Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site" http://support.microsoft.com/kb/940726James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
June 1st, 2011 3:07pm

Sites is an SBS thing - I think it is where the Sharepoint sites are stored. I know when I do an SSL certificate for SBS 2008 I include "Sites" as one of the additional names in the certificate. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
June 1st, 2011 3:15pm

Yes, it shows "Attempting URL https://sites/Autodiscover/Autodiscover.xml found through SCP" as the first line. The CNAME thing refers to changing the entry on the DNS server. So instead of connecting to "sites", it silently can't connect. This would seemingly break the autodiscover, but I'm not sure what else. That support article is about changing the default certificate for an external one, and telling Outlook to connect to the external FQDN - but returning a private LAN address for LAN clients. I had seen this before, but didn't think it applied. Checking the autodiscover test on another SBS client (different company/server), I see that SCP is directing Outlook to go to the external FQDN (which returns as a private LAN address). It looks like I should use that article after all and change it from "sites" to the FQDN - with slight modifications for SBS. I've run the following commands, and they now match the working server, but Outlook is still returning the "sites" thing in autodiscovery. Set-WebServicesVirtualDirectory -Identity "SERVER01\EWS (SBS Web Applications)" -InternalUrl https://remote.domain.com.au/EWS/Exchange.asmx Set-OabVirtualDirectory -Identity "SERVER01\OAB (SBS Web Applications)" -InternalUrl https://remote.domain.com.au/oab -ExternalUrl https://remote.domain.com.au/oab Set-UMVirtualDirectory -Identity "SERVER01\UnifiedMessaging (SBS Web Applications)" -InternalURL https://remote.domain.com.au/UnifiedMessaging/Service.asmx I think we're really close.. but must be something else. Perhaps some kind of service restart/cache flush (yes I did the Recycle thing from that article).
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2011 7:34am

The other SBS2008 server I've compared this to has the same SSL error when directing a web browser to https:\\sites\ so I don't think it's a case of it going to the right place, but getting the wrong certificate. It's going to the wrong place (sites) instead of the FQDN - based on comparisons of Outlook's autodiscover test (noted above).
June 2nd, 2011 7:36am

That is an odd setting. I haven't seen SBS 2008 do that before. However easily corrected. Run the following command, but replace "mail.example.net" with the common name on your SSL certificate - so usually remote.example.com Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mail.example.net/autodiscover/autodiscover.xml Then run IISRESET from a command prompt. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2011 7:47am

You're a champ. That's one fairly well undocumented thing :) The DNS is set back to how it was and Outlook is behaving itself. The autodiscover test shows the right FQDN. Thank you both, Jamestechman and Sembee.
June 2nd, 2011 11:04am

Thanks for your udpate and confirmation. Again, thanks for choosing Microsoft. -FionaPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
June 19th, 2011 10:00pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics